1. Field of the Invention
This invention pertains to electronic devices used to test and debug electrical circuits and, more particularly, such devices that use a Joint Test Action Group (JTAG) port.
2. Description of the Related Art
With the complexity and increase of pin-count of new computer chips and the dense assembly of these chips on circuit boards, it becomes increasingly difficult to test and debug the circuit boards after being assembled. A group of leading electronic companies has joined forces and developed a standard test port to be built on every chip. The purpose of this test port is to allow connection to a test tool to check the value of each pin on the chip. Some chips add more functionality to this test port to provide access to virtually any resource inside the chip. One example of an in situ test port is the “JTAG” (Joint Test Action Group) test port adopted by the Institute of Electrical and Electronics Engineers, Inc, and defined as the IEEE standard 1149.1.
A common use of a test port is to test the components of a circuit board such as memory, Flash, Input/Output chips and the on-board CPU. The test port can also be used to test the solder joints and the functionality of some of the onboard chips, and to program FLASH memory chips.
Typically, the testing tool is connected to a host computer that is used to input information and display the test results. The testing tool includes an I/O interface that connects via a port, such as SCSI, serial, parallel or Ethernet to the host computer. Typically, the testing tool CPU is also connected to a test-bus controller chip that allows the testing tool CPU to access the test port. When the testing tool uses a JTAG test port, a JTAG bus controller with its own chip is used.
In situations where test speed is not important, the CPU can just toggle some I/O pins that are connected to the test port to emulate the port protocol. In another implementation the test tool can be built into an add-on card that connects directly to the host computer motherboard. In such implementations, the host computer CPU can also serve as the test tool CPU.
During testing procedures, called a SCAN in case of JTAG, the testing tool is used to deliver a stream of bits to the test circuit. Upon receiving the bits, the test circuit responds by sending back a response stream of bits. By examining the response stream of bits, the test tool and the host software can determine the state of the test circuit and whether, for example, there are shorts or open solder points in the test board.
The incoming and outgoing test bits are normally stored in the main memory of the testing tool. In a typical SCAN test, the CPU reads the data from the main memory and then writes it to the test-bus controller. Some test-bus controllers have an input and output FIFO that allow the CPU to read and write larger data blocks. A DMA (Direct memory access) device can be used, if the controller chip has DMA control signal, such as request and acknowledge. Also since the number of bits in a SCAN test can vary from one to thousands of bits, it has to be determined if programming the DMA controller would take more time then using the CPU to write the data directly to the test-bus controller.
The CPU must wait until the test-bus controller sends the outgoing data to the board under test. If incoming stream of data is expected, the CPU has to read it from the test-bus controller and store it for further analysis. Again, since the number of bits can vary between one and thousand of bits, it has to be determined if an interrupt scheme can be used to interrupt the CPU after the results are received since an interrupt overhead might take more time then waiting for the data. Even though the results can be stored in the CPU registers, if the results are sufficiently small (i.e. 32 bit or less), most software compilers will store the results in the main memory. The CPU uses standard logic operations such as OR, NOT or AND to check the results of the test. These test operations can be repeated as many times as needed to check the functionality of the board under test. The results can then be sent to the host computer to be displayed to the operator.
It should be understood that a substantial amount of time is wasted due to the relatively extensive communications between the test-tool CPU, the memory and the test-bus controller. There are three reasons for the slow communications.
First, because the test-bus controller is connected to the main CPU as a peripheral, the main CPU must supply the test-bus controller with instructions to execute a specific test. It might take the main CPU hundreds of assembly instructions to supply the test-bus controller with a test instruction (such as SCAN_IR in JTAG). Since current test-bus processors, as shown in FIG. 1, do not offer an instruction FIFO, the main CPU usually must wait until the current instruction is completed before supplying the next one. One of the major difficulties of adding an instruction FIFO is the need to synchronize the instruction FIFO with the data FIFO.
Secondly, because the test-bus controller cannot execute any logic operations, it has to wait for the main CPU to execute these operations to test the incoming data from the test board. Upon examination of the board results, the main CPU can give further instructions to the test-bus controller. With the current solution, it is difficult to add an Arithmetic-Logic Unit (hereinafter known as ALU) since the data is read and written in a FIFO, which cannot be addressed reliably since the data location in the FIFO depends on the speed of the main CPU and the speed of the test-bus connected to the test board.
Thirdly, because the test-bus controller cannot directly address and access the memory where the test data is stored, the main CPU (or a DMA channel) must act as the bridge between the test-bus controller and the memory where the test data is stored. Since the test-bus processor has to access different test vectors in a singe test, the CPU has to calculate the address for each one. This task is very time consuming. The reason that the test-bus controller cannot access the memory directly is because it does not have an address bus to address and access individual memory locations making it a memory-bus master.